home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 642 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.8 KB
  1. Path: teal.csn.net!not-for-mail
  2. From: thads@csn.net (Thad Smith)
  3. Newsgroups: comp.std.c
  4. Subject: Re: externsions and Standard C
  5. Date: 23 Mar 1996 18:53:28 -0700
  6. Organization: T3 Systems
  7. Message-ID: <wOKVxQ9ytZSb084yn@csn.net>
  8. References: <4gum82$14v4@info4.rus.uni-stuttgart.de>
  9.  <MPLANET.31530e9djcoffin98993e@news.rmii.com>
  10.  <31536199.219868914@nntp.ix.netcom.com> <315418FA.1508@iadfw.net>
  11.  <1996Mar23.202452.14793@sq.com> <31547BB8.31D7@iadfw.net>
  12. Reply-To: ThadSmith@acm.org
  13. NNTP-Posting-Host: 199.117.27.22
  14.  
  15. In article <31547BB8.31D7@iadfw.net>, Larry Weiss <lfw@iadfw.net> wrote:
  16. >Mark Brader wrote:
  17. >> 
  18. >> lfw@iadfw.net writes:
  19. >> > Mike Rubenstein wrote:
  20. >> >  > You've missed a rather subtle point.  Such extensions are legal but
  21. >> >  > they do not introduce integer types.  The standard defines the signed
  22. >> >  > integer types as being signed char, short int, int, and long int (and
  23. >> >  > similarly for unsigned integer types).
  24. >> 
  25. >> > It must be pretty subtle!
  26. >> 
  27. >> Not at all.
  28. >> 
  29. >> > Can you cite specific Clause references ...
  30. >> 
  31. >> It's in 6.1.2.5/3.1.2.5:
  32. >> 
  33. >> # There are four "signed integer types", designated as signed char,
  34. >> # short int, int, and long int ...
  35. >> 
  36. >> It says four, not four or more.
  37. >> 
  38. >> # For each of the signed integer types, there is a corresponding
  39. >> # (but different) "unsigned integer type".
  40. >> 
  41. >> It is true that size_t is specified by 6.3.3.4/3.3.3.4 as having an
  42. >> "unsigned integral type" rather than "unsigned integer type", but the
  43. >> draft Record of Reponse 2 confirms that these terms were not intended
  44. >> to be distinguished.
  45. >> 
  46. >> Thus if x is of type size_t, printf ("%ul\n", (unsigned long) x); is
  47. >> safe under the present standard.
  48. >> --
  49. >
  50. >
  51. >Let me try one more time to understand what makes an extension "legal"
  52. >and what makes an extension "impossible".   
  53. >
  54. > Am I correct to understand that it is impossible for an implementation
  55. >to define an extension that introduces new integer types?  (I'm pretty sure
  56. >answer if "yes" for the above stated reasons).
  57.  
  58. In general, extensions may be added, and the implementation remain
  59. conforming, as long as the strictly conforming programs are translated
  60. correctly.  The cited paragraphs define what is meant by
  61. "unsigned integral type" in the Standard.  Certainly more data types,
  62. including what otherwise would be called integral types, can be added
  63. to the implementation, but when the Standard says that a type is an
  64. unsigned integral type, it is referring to the closed definition of
  65. unsigned integral type in the Standard.  
  66.  
  67. The ability to cast a size_t to unsigned long without loss of value is
  68. an example of the value of this interpretation.  Note that the
  69. definition of size_t does not allow for overflow, as with ptrdiff_t,
  70. so that the type of size_t constrains the maximum allowable object
  71. size, IMO.
  72.  
  73. Thad
  74.